1. Field of the Invention
The present invention relates to a method, a system, and a computer program product for managing virtual instances of a physical port attached to a network.
2. Background Art
More specifically, the invention relates to a network, in which each connected computer or device has a unique identifier. As an example, a network with Fibre Channel connections is described.
Functionally, the Fibre Channel (FC) is a bi-directional, full-duplex, point-to-point, serial data channel structured for high performance data communication. The FC provides a generalized transport mechanism that has no protocol of its own or a native input/output command set, but can transport any existing Upper Level Protocols (ULPs) such as FCP, the “Fibre Channel Protocol for SCSI (Small Computer System Interface)”, and IP, the Internet Protocol.
The smallest, indivisible unit of information transfer used by FC is called a frame. Frames are used for transferring data. The frame size depends on the hardware implementation and is independent of the ULP or the application software. These frames are aggregated to form messages called sequences. The frames of a sequence can be received out of order. One or more sequences form an exchange, which is a basic transaction. The frames are divided in two categories: link control frames without data payloads, which are used for the flow control, and data frames with data payloads such as encapsulated ULP data.
Various FC standards exist, for example the following references:                1. Information Technology—Fibre Channel Protocol for SCSI, 2nd Version (FCP-2), ANSI/INCITS 350        2. Information Technology—Fibre Channel Framing and Signalling Interface (FC-FS), ANSI/INCITS 373.        
Further details about FC can be found for example in Robert W. Kembel, “The Fibre Channel Consultant—A Comprehensive Introduction”, 1998.
Connecting a computer or other device to a FC requires specific hardware. FC hardware is usually provided in the form of FC adapter cards which are plugged in existing input/output (I/O) hardware such as PCI/PCI-X/PCI-Express slots of a computer system. Every FC adapter contains at least one N_Port, a FC hardware entity which performs the actual data communication over the FC link.
An N_Port is identifiable by a unique Worldwide Port Name (WWPN) implemented as a 64-bit value. This WWPN is normally assigned at manufacturing time of the FC hardware, but may also be assigned by other means, provided that the port name can be guaranteed to be unique worldwide. An N_Port can act as an originator or a responder.
FC connections may be implemented as a point-to-point link, or an arbitrated loop or a switching network, called a fabric.
A FC fabric is an interconnection network that allows multiple N_Ports to intercommunicate. The entry/exit ports on a fabric are called F_Ports, and each N_Port has to connect to one F_Port. The fabric allows each connected N_Port to communicate with any other N_Port that is attached to the fabric.
The FC fabric assigns to each attached N_Port an identifier, which is an address by which an N_Port is uniquely known for the fabric. Since the N_Port identifier is a 24-bit value, a FC fabric can support up to 16.7 million N_Ports. The N_Port identifier consists of a Domain (most significant byte), an Area, and a Port, each 1 byte long. The N_Port identifier is used in the Source Identifier (S_ID) and Destination Identifier (D_ID) fields of the header of a FC frame.
Initiating communications in a fabric requires a multistage login process in which communications are first established between an N-port and an F-port in the fabric and then with the destination N-port. In the first step, the fabric login of the N_Port establishes the classes of service to be used within the fabric and other communications parameters including flow control information. After the fabric login of the N_Port completes, the initiating and recipient N-ports in the network establish communications with each other through a second login process called node logic Several communication parameters are exchanged and the transmission starts. As FC can be used to connect systems with multiple types of internal resources and processes within, an additional login called a process login is used. For example, the process login is used to select parameters related to an ULP supported by processes within two communicating N_Ports.
The vast majority of today's FC adapters provide one N_Port only. In a computer executing multiple operating system (OS) instances, the problem occurs how to share such an N_Port among these instances. Such sharing would be advantageous to minimize the number of FC adapters, to reduce cost and to maximize adapter utilization, especially for large scale virtualisation environments. The problem exists even when using FC adapters providing multiple N_Ports since the number of processes needing to be supported often exceeds the number of N_Ports provided by the FC adapters.
The capability to execute multiple OS instances is usually provided by a software layer called (execution) hypervisor that encapsulates the underlying hardware and provides virtual hardware interfaces either for the underlying hardware or for different hardware architectures. For example, a hypervisor can be part of the firmware of a computer system, it can be part of an operating system, or it can be a regular program running as a process within an OS instance. The work of the hypervisor is often supported by additional hardware features, for example special processor instructions or firmware layers.
Some hypervisors can effectively create multiple virtual images of a computer system, giving an OS instance executing in such a virtual computer system almost the illusion as if it was running exclusively on the real server. These OS instances access real I/O entities (like adapters) via I/O ports, which can be defined and assigned to a virtual computer system in a configuration step. An OS instance may only perform I/O operations using I/O ports assigned to the particular virtual server on which it is running.
The U.S. patent applications No. 2003/0200247A1 and No. 2004/0025166A1 describe a method for the concurrent sharing of a FC adapter among multiple OS instances in a computer system. However, this sharing capability has various deficiencies caused by the fact that the same N_Port identifier is used for all FC frames sent from or destined to a particular FC adapter. Consequently, this N_Port identifier cannot be used to distinguish multiple OS instances: All of the frames seem to come from the same initiator, and responses are accordingly sent back to the same address. The solution proposed in the above patent applications is to intercept, analyse, and modify the FC frame traffic between the multiple OS instances and the physical N_Port.
A major disadvantage is that this solution is host-based, which means that the approach needs to be performed on a host computer system that is attached to a FC fabric. Since FC is a technology used mainly for Storage Area Networks (SAN), and the usual method for access control in the SAN and its attached storage devices is managed by the SAN itself (using databases stored in the fabric), this adds additional complexity to the SAN management and administration.
Another disadvantage is that it is not possible to initiate a FC transaction to a particular OS instance from outside of the computer system executing the multiple OS instances. This limitation is caused by the need for the unequivocal response identifier that gets added to the frame header when it gets intercepted. There is only one response identifier to be used for frames that will be sent to a particular OS instance. Without being able to identify the specific OS instance, any incoming frame has to be forwarded to every OS instance. An OS instance needs to decide then if it will accept and process the frame.
Other deficiencies that exist in such a shared adapter environment are related to ULPs such as FCP; for example, SCSI reservations do not work properly, correct SCSI status and sense data handling cannot be guaranteed, SCSI task management functions do not work properly, and vendor-unique SCSI commands might not work at all.
SAN access control for the connected storage controllers of a fabric is typically implemented by methods like zoning and SCSI Logical Unit (LUN) masking. Zoning and LUN masking rely on WWPNs to identify users of controlled assets. Using a LUN and FCP as the ULP, a FC host can address multiple peripheral devices that may share a common controller. Zoning allows partitioning the N_Ports of a fabric into N_Port groups, called zones. The N_Port within a zone can only communicate with other N_Ports in the same zone.
One way to solve the FC adapter sharing problem was disclosed in the U.S. patent application No. 2003/0103504A1 and later on incorporated in the INCITS/ANSI FC Framing and Signalling (FC-FS) standard 1.6, which describes how a fabric needs to handle N_Port identifier virtualisation. The application describes a method to obtain multiple N_Port identifiers (N_Port IDs) for a single physical N_Port.
In order to obtain an N_Port identifier, the N_Port first logs in with the fabric by sending a “Fabric Login” (FLOGI) extended link service (ELS) command (a special link control frame) to the attached F_Port. In this step additional service parameters will be transferred, and the first N_Port identifier is assigned. After FLOGI is complete, the fabric prepares itself to assign additional N_Port identifiers. In order to obtain another N_Port identifier, the N_Port sends a “Fabric Discover” (FDISC) ELS command using an S_ID of zero. The FDISC ELS is used instead of additional FLOGI commands to avoid disruption of the operating environment. When the N_Port sends the FDISC ELS to the fabric, it provides the following functions:                1. It provides the means for the physical N_Port to transfer a WWPN to the fabric.        2. It provides a signal to the fabric to validate and assign an additional N_Port identifier for the physical N_Port, and allows both the fabric and the physical N_Port to begin normal frame reception and transmission using the new N_Port identifier.        3. It provides a signal which causes the fabric to update databases maintained within the fabric.        
When the new N_Port ID has been assigned, the physical N_Port can associate the new N_Port ID with a virtual adapter, which is an entity behind the physical N_Port that generates and receives frames using the new N_Port ID on behalf of an OS instance. Therefore, multiple virtual adapters can be associated with a physical adapter and its N_Port, where each virtual adapter uses a unique N_Port ID.
The assignment of new N_Port IDs requires the availability of unique WWPNs and means for the automatic and persistent assignment of these WWPNs to virtual adapters, where persistent can mean surviving e.g. a reboot of an OS instance, a power-off/power-on cycle of the computer system, or a reboot of a FC adapter. In large scale computer centres with complex SAN installations it can become therefore a very complex task to ensure that every WWPN in use is really unique.